As semiconductor devices become smaller and are placed in ever smaller packages, the space occupied by the input/output pins of an integrated circuit contributes significantly to the overall area of the packaged semiconductor device. Thus, device size can be reduced by reducing the number of pins on each integrated circuit. One way to reduce the number of pins is to share a single pin for both the transmit and the receive operations. A single-pin interface can be used both to transmit and to receive data signals conforming to the well-known “RS232” asynchronous protocol.
Where data signals are received into a memory buffer of a receiving device, the receive buffer can overflow unless the flow of data is controlled. For example, a receive buffer can overflow when data is received too quickly from a single-pin interface. The receive buffer overflows if data is not read out of the receive buffer faster than data is received from the single-pin interface. For example, a receive overrun problem can occur where the receiving device is a personal computer (PC) that receives sixty-four Kbytes of data from a FLASH array into a 16-byte first-in-first-out (FIFO) memory buffer in a universal asynchronous receiver/transmitter (UART). The operating system running on the PC ideally reads some bytes of data out of the memory buffer before more bytes of data are loaded into the memory buffer. The memory buffer overflows, however, where an application or driver that is running on the operating system does not release control back to the central processing unit (CPU) of the PC quickly enough after the CPU receives an interrupt command to read the memory buffer.
A flow control mechanism is needed to solve the receive overrun problem by interrupting the transmission of bytes of data in the middle of a communication stream. Various hardware and software flow control mechanisms have been implemented with bidirectional, full-duplex communication protocols, such as RS232.
Hardware flow control uses additional signaling lines to throttle the data rates transmitted by the target device. Hardware flow control is not possible on a single-wire communication bus because hardware flow control requires additional control signals to be sent over additional wires. Hardware flow control is not appropriate for small pin-count devices because it requires the use of an additional pin.
Software flow control involves the receiving device sending XON and XOFF commands to the transmitting device causing pauses in the data transmission. Software flow control is not possible on a single-wire communication bus that supports only half-duplex communication. The XON and XOFF flow control commands can be sent only in full-duplex communication. The receiver cannot send an XOFF command to the transmitter if the receiver is receiving data on a half-duplex communication channel.
Some existing implementations of flow control on a single-wire communication bus have obviated the need for flow control by limiting the size of read requests. These implementations employ polling with a “read command.” A host sends a “read command” to request data from a target. Flow control is inherently implemented in that the host controls how much data it requests. Flow control is not necessary, for example, where the host requests only one byte of data at a time. Reading only one byte of data at a time in response to a read command, however, is slow and inefficient. If the host requests a larger block of data from the target, flow control again becomes a problem because there is no way to pause the data transmission once it has started.
A method is sought for implementing flow control for a large block of data over a single-wire communication bus.